1. Field of the Invention
Embodiments of the present invention relate to event handling devices that generate event logs, and specifically to network communications devices which generate syslog entries from the application of rules.
2. Related Art
Event handling devices are common. Such devices apply a particular set of rules to a given situation, in that particular set of circumstances arises, one or another of the rules in the rule set is applicable to the circumstances. One area in which these event handling devices are often used is that of network security appliances, for example, an ASA/PIX/FWSM firewall.
Network security appliances are connected to a network, or several networks, through designated interfaces. Network traffic flow through the security devices is governed by the application of a set of related rules, or an interface instruction set. These interface instruction sets in turn, are made up of many rules. The rules specify, for example, what traffic is allowed to go where, and using which protocol. Because the application of these rules to network traffic is of interest, the outcome of each individual application of rule, called an event, is recorded in a system log, or syslog.
Unfortunately, any particular syslog entry does not pinpoint exactly which rule triggered its creation. In the case of most ASA/PIX/FWSM firewalls for example, a typical log entry will specify which interface instruction set was involved in generating the syslog entry, but will not identify the exact rule. The knowledge of which rule generates a particular syslog entry can be important to, for example, a network administrator who wishes to see whether a particular rule is having the desired effect on the network. Without the ability to determine whether a particular rule is functioning or not, such a network administrator is reduced to using experimentation to determine whether rule is performing as expected.
Several approaches are currently being used as a means of addressing this particular problem. One is the idea of using sequential numbering of rules within an interface instruction set, and then appending that sequential number to the syslog entry. However should any reordering of rules occur within the interface instruction set, for example through the addition, deletion, or modification of any rule, any syslog entry that use the old ordering would no longer be accurate. Another approach would be to use a counter that increments each time a rule is added or changed. The value associated with a given rule would be appended to the syslog entry. A problem with this approach is that it is difficult to determine which value is associated with a given rule. Further, rule addition and modification across multiple devices would yield different numbers for a particular rule, unless rule entry and modification were exactly uniform, at all times. A common failing of both of these approaches is that in a network having many devices that apply these rules, every device would have to have identical numbering for their interface instruction set rules, if the scheme was to have any value to the administer at all. This, in turn, would necessitate some sort of nonvolatile storage that would store these rules across all of the devices. However, accessing nonvolatile storage is an extremely expensive operation.
Another possible solution would be to print out the entire rule that triggered a syslog entry in the syslog itself. There are several problems with this approach as well. First, it is expensive, in terms of bit operations, to concatenate a string, as well as to then transmit the now much larger syslog entry over a network. Second, whenever system receives the syslog event has to parse the string, using a string matching operation, which is also extremely expensive.
This issue is further complicated by the expansion problem. The expansion problem is simply that a rule can be assembled using object lists, where each object list has many possible valid values. As such, a system administrator can write a single rule, using object lists, that when expanded could have hundreds or potentially thousands of valid instantiations. For example, a network traffic access rule would likely specify the acceptable protocols to use for conducting traffic. The rule could simply specify the name of a defined object list, and then any protocol that appeared on that object list would be acceptable according to the rule. This rule could be written out in an expanded form, in which case it would take as many rules as there were acceptable protocols on the object list. In applications where a rule may have many different possible object lists, and the object lists themselves may have many entries, including other object lists, the total number of expanded rules within the system could be unmanageable, if they had to be handled individually.